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Abstract — Software metrics is applied evaluating and assuring 
software code quality, it requires a model to convert internal 
quality attributes to code reliability. High degree of complexity 
in a component (function, subroutine, object, class etc.) is bad 
in comparison to a low degree of complexity in a component. 
Various internal codes attribute which can be used to indirectly 
assess code quality. In this paper, we analyze the software 
complexity measures for regression testing which enables the 
tester/developer to reduce software development cost and 
improve testing efficacy and software code quality. This 
analysis is based on a static analysis and different approaches 
presented in the software engineering literature. 

Index Terms — Software Complexity, Software Metrics, 
Regression Testing, Control Flow Metrics 1 . 

I. Introduction 

The Software complexity is based on well-known software 
metrics, this would be likely to reduce the time spent and 
cost estimation in the testing phase of the software 
development life cycle (SDLC), which can only be used after 
program coding is done. The path count complexity of a 
function is defined as product of the path complexity of 
individual constructions. Improving quality of software is a 
quantitative measure of the quality of source code. This can 
be achieved through definition of metrics, values for which 
can be calculated by analyzing source code or program is 
coded. A number of Software measures widely used in the 
software industry are still not well understood [2]. Although 
some software complexity measures were proposed over thirty 
years ago and some others proposed later. Sometimes 
software growth is usually considered in terms of complexity 
of source code. Various metrics are used, which unable to 
compare approaches and results. Not all metrics are similarly 
easy to calculate for a given source code. [4]. Software 
systems are maintained by designers by doing regression 
test periodically in expect to find bugs caused by modifications 
and hoping that modifications made in the software are 
correct. Software engineering goal is to measure different 
aspects of software projects, to find small set of attributes 
that may characterize them. This paper presents an approach 
by which tester/developer can reduce software development 
cost and improve testing efficacy and software quality. 
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II. BACKGROUND DETAILS 

A. Regression Testing 

Regression testing is a process that seeks to uncover errors, 
which is performs after changes are made to program and can 
be used before release of modified program. Regression test 
can be perform rerunning the existing test suites against 
modified program whether the changes are correct and have 
no effect to unchanged part of the program. Regression test 
can be performing with adequate coverage that should be 
the primary consideration. A regression test compares the 
operation of the new version of software to the operation of 
a older version. The key idea is that the behavior of the 
program should not change in unanticipated ways. 
Regression testing ensures that we do not introduce new 
bugs or resurrect old ones. Testing of software is an integral 
part and key component of the software development 
process. This testing process can be used to test a system 
efficiently by selecting minimum set of test suite needed to 
that change. Regression testing techniques can be described 
as follows: Let P be a program, and P' be a modified program 
of P, and T be a test suit for program P. Regression testing 
can be attempt to revalidate modified program P'. From 
software engineering point of view software development 
experience shows, that it is difficult to set measurable targets 
when developing software products. Produced/developed 
software has to be testable, reliable and maintainable. On the 
other side, "You cannot control what you cannot 
measure" [3]. To avoid this, regression testing is performed 
during changes are made to existing software; the purpose 
of regression testing is to provide modified program do not 
obstruct existing, unchanged part of the software 
[1]. Complexity of software is measuring of code quality; it 
requires a model to convert internal quality attributes to code 
reliability. High degree of complexity in a component (function, 
subroutine, object, class etc.) is bad in comparison to a low 
degree of complexity in a component is considered good. 
Software complexity measures which enables the tester to 
counts the acyclic execution paths through a component and 
improve software code quality. In a program characteristic 
that is one of the responsible factors that affect the developer's 
productivity [6] in program comprehension, maintenance, and 
testing phase. There are several methods to calculate 
complexity measures were investigated, e.g. different version 
of LOC [6], NPATH [7], McCabe's cyclomatic number [10], 
Data quality [10], Halstead's software science [8] etc. 



14 



^cACEEE 



ACEEE Int. J. on Information Technology, Vol. 01, No. 02, Sep 201 1 



B. Software Complexity Metrics: Properties 

Complexity of software can be measure by selected 
properties that cause complexity. Some properties influencing 
the complexity are as follows: 

• Size metrics 

•Control flow metrics 

1. Size metrics : Lines of Code 

The size of the program indicates the development 
complexity, which is known as Lines of Code (LOC). The 
simplest measure of complexity recommended by Hatton 
(1977) . This metric is very simple to use and measure the 
number of source instruction required to solve a problem. 
While counting a number of instructions (source), line used 
for blank and commenting lines are ignored. The size, 
complexity of today's software systems demands the 
application of effective testing techniques. Size attributes 
are used to describe physical magnitude, bulk etc. Lines of 
code and Halstead's software science[8] are examples of size 
metrics. M. Halstead proposed a metrics called software 
science [ Halstead 77]. 

2. Control Flow metrics: NPATH 

The control flow complexity metrics are derived from the 
control structure of a program. The control flow measure by 
NPATH, invented by Nejmeh [7] ,it measures the acyclic 
execution paths, NPATH is a metric which counts the number 
of execution path through a functions. NPATH is example of 
control flow metrics. One of the popular software complexity 
measures NPATH complexity (NC) is determined as: 

N PATH =nSf .^(statement) 

NP (if)=NP(expr)+NP(if-range)+l 

NP(if-else)=NP(expr)+NP(if-range)+NP(else-range) 

NP(while)=NP(expr)+NP(while-range)+l 

NP(cb-while)=NP(expr)+NP(do-range)+l 

NP(for)=NP(for-range)+NP(exprl)+NP(expr2) + 

NP(expr3) + l 
NP("?")=NP(exprl+NP(expr2)+NP(expr3)+2 

NP(repeat)=NP(repeat-range)+l 

NP(switch) = NP(expr)+Ii=J i i V J P(ca5ff -ran 3 B}+ 

NP (default- range) 
NP (function call) = l 
NP(sequential)=l 
NP( return) =1 
NP(continue) = l 
N P( break) =1 
NP( goto label) = 1 

NP(expressions)=N umber of && and 1 1 operators in 
Expression 

Execution of Path Expressions (complexity expression) are 
expressed, where "N" represents the number of statements 
in the body of component (function and "NP (Statement)" 
represents the acyclic execution path complexity of statement 
i. Where "(expr)" represents expression which can be derived 
from flow-graph representation of the statement. For example 
NPATH measure as follows: 

Void func-if-with-assignment ( int c) 
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{ 

int a=0; 
if(c) 

{ 
a=l; 

} 
} 

The Value of NPATH is 2 as follows: 

NP(if)=NP(if-range)+NP(expr) + 1 

3. McCabb'e Cyclomatic Complexity [10] 

Cyclomatic Number is one of the metric based on not 
program size but more on information/control flow. It is based 
on specification flow graph representation developed by 
Thomas J Mc Cabb in 1976. Program graph is used to depict 
control flow. Nodes are represent processing task (one or 
more code statement) and edges represent control flow 
between nodes. McCabe's metrics[10] is example of control 
flow metrics. To compute cyclomatic complexity V(G) as 
following methods: 

1. For graph G with N vertices(nodes), E edges and P 
connected components, 

V(G)=E-N+2p 

2. V(G)= Total number of bounded area +1 
Where bounded area is in program's CFG any region 
encoded by nodes and edges. 

3. Number of decision statement of the program + 1 or 
number of predicate node+1 

The problem with McCabb's Complexity is that, it fails to 
distinguish between different conditional statements (control 
flow structures). Also does not consider nesting level of 
various control flow structures. NPATH, have advantages 
over the McCabb's metric [7]. 

4. Halstead Software Science [8] 

Another alternative software complexity measures have 
to be considered. M. Halstead's Software science measures 
[8] are very useful. Halseatd's software science is based on a 
enhancement of measuring program size by counting lines of 
code. Halstead's metrics measure the number of number of 
operators and the number of operands and their respective 
occurrence in the program (code). These operators and 
operands are to be considered during calculation of Program 
Length, Vocabulary, Volume, Potential Volume, Estimated 
Program Length, Difficulty, and Effort and time by using 
following formulae. 
n l = number of unique operators, 
n = number of unique operands, 
N = total number of operators, and 
N 2 = total number of operands, 
Program Length (N)=N1+N2 
Program Vocabulary ( n)=n 1 +n2 
Volume of a Program ( V)=N*log,n 
Potential Volume of a Program 
(V*)=(2+n 2 )log 2 (2+n 2 ) 
Program Level (L)=L=V* /V 
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Program Difficulty (D)=l/L 

Estimated Program Length (N)=n 1 log,n 1 +n,log,n 7 

Estimated Program Level (L)=2n7(n ] N2) 

Estimated Difficulty (D)=l/L=n 1 N/2n, 

Effort (E)=V/L=V*D= (n 1 x N 2 ) / 2n 2 

Time (T)=E/S ["S" is Stroud number (given by John 

Stroud), The constant "S" represents the speed of a 

Programmer. The value "S" is 18] 

One major weakness of this complexity is that they do not 

measure control flow complexity and difficult to compute 

during fast and easy computation. 

m. OUR METHODOLOGY 

Our method deals with analysis of software complexity 
metrics for regression testing. We have considered four 
program characteristics from the literature that are 
responsible for complexity measures, viz LOC, NPATH, MCC, 
and HSS. For this study, we have selected only program 
written in C language given in Figure 1 and Figure 2. The 
structure of a program P ad P' can be represented by a control 
flow graph in figure 3, G(P)={N,E,s,e}, where N is a set of 
nodes representing basic blocks of code or branch points in 
the function; Eis a set of edges representing flow of control 
in the function; s is the unique entry node and e is the unique 
exit node 



A. 



Methods: 



There are four steps can be used to collect the data as 
described below. We compute weights of software complexity 
metrics for original program P and modified program P' 
(required element): 

Step 1: Compute LOC by counting frequency of line 
numbers. 

(i) Blank lines and 
(ii) Commenting lines are ignored. 

Step 2: Calculate the NPATH complexity measures 
also known as path count metrics. 

Step 3: Compute McCabe complexity. 

Step 4: Count the Halstead's Software science of software 
primitives. 

B. Selected Metrics 

We have measured LOC, NPATH i.e. acyclic execution 
paths through components for in an attempt at program 
optimization, McCabe and finally Halstead's software science 
complexity metrics. While counting a number of instructions 
(source), line used for blank and commenting lines are 
ignored. NPATH measures the acyclic execution paths which 
counts the number of execution path through a functions. 
Halstead's metrics measure the number of number of operators 
and the number of operands and their respective occurrence 
in the program (code). These operators and operands are to 
be considered during calculation of Program Length, 
Vocabulary, Volume, Potential Volume, Estimated Program 

Length, Difficulty, andEff ort and time FbrMcCabb's 
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complexity measures program graph is used to depict control 
flow. Nodes are representing processing task (one or more 
code statement) and edges represent control flow between 
nodes. Consider an example, Let P be the old version of 
program and P' be the new version of program in C given 
below: 

Consider a program from figure 1 . the complexity measured 
by us and computed the complexity of the other proposed 
measures i.eLine of Code (LOC), NPATH Complexity (NC), 
McCabb's complexity (MCC) and Halstead's software science 
(HSS). In Figure 2, we have done some modification to the 
given example of program P i.e some lines are added in the 
existing program. Some changes are made for regression 
testing in the existing program and calculated measures from 
both the programs P and P' in Table 1 and Table II as follows: 



#include<stdio.h> 
void main() 

{ 

int a,b,c,n; 

scanf("%d %d", & a,&b); 

if(a<b) 

{ 

c = a; 

} 

else 

{ 

c = b; 

} 

n = c; 

while ( n < 8 ) 

{ 

if ( b > c ) 

{ 

c = 2; 

} 

else 

{ 

n = n + c +7; 

} 

: n = n + 1; 

} 

Printf("%d%d%d",a,b, n); 



Figure 1 . Source Program P 



#include<stdio.h> 
void main() 

f 

int a,b,c,n; 

scanf("%d %d", & a,&b); 

if(a<b) 

f 

c = a; 

} 

else 

f 

c = b; 

} 

n = c; 

while ( n < = 8 ) 

f 

if ( b > c ) 

{ 

c = 2; 

} 

else 

{ 

n = n + c +7; 
if ( n % 7 == ) 
( 

: c = c + 2; 
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lsc 



Printf("%d%d%d",a,b, n); 



Figure 2. Modified Program P' 





Figure 3. Control Flow Graph for Program P and P' 
Table I. Computed weights software complexity measures from program P 
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Table II. Computed weights software complexity measures from 
Program P' 
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C. Equivalent Size Measures ( ESM): 

Equivalent size measures is code redundancy inside a 
program maybe viewed as the intra-program re-use of code. 
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This measure is used by S.D Conte in the year of 1986 [6]. 
The equivalent size measure is basically effort required to 
develop software with new code and re-use code is equivalent 
to the effort of developing the same software. During software 
development, most of the time re-uses software from the 
previous code/program. It has been reported that, at IBM's 
Santa Teresa Laboratory, 77% of all program code is written 
in place to add new code to existing code [6]. Formula 
proposed by Bailey and Basili [6] is used to compute the 
equivalent size measure as follows: 

Se=Sn+.02* Su 

Where, Se is equivalent size measure 

Sn is a measure for newly written code 

and Su is a measure for redundant/re-use code 

(adopted from existing code) 

Considering a program P and P', we are able to 

extract the following equivalent size measures: 

Su=24 (i.e. consider as redundant/ re-use code) 

Sn= 34-24 (i.e .the total lines of code subtract the 

lines of redundant/re-use code) 

Se= Sn+0.2*Su 
= 10+0.2*24 
=15 (LOC) 
Equivalent size measure (ESM) may be helpful during 
measurement of software maintenance phase. In this paper, 
we work with four program characteristics measures. From 
the above table I and Table II, it is also identified that change 
behavior of program characteristics 

IV. Conclusion 

Software complexity metrics have a propensity to be used 
in judging the quality of software development and metrics 
are relatively easy to generate. The size, complexity and 
importance of today's software systems demand the 
application of effective testing techniques. In addition, it was 
observed that software complexity metrics which enables the 
tester to counts the acyclic execution paths through a 
component and improve software productivity and software 
quality. This approach could be lead to reduce software 
development cost and improve testing efficacy and software 
quality. Software metrics with Lines of Code (LOC), Npath 
(NC), McCabb's complexity metrics (MCC) and Halstead's 
Software science (HSS) are calculated and observed the 
change behavior of the code. Finally, the evaluated values 
from both P and P' , the changed behavior of code is identified 
and tester can use this approach to execute test case and 
improve software productivity and software quality. In the 
future study, more complicated program has to be measured 
with other attributes (complexity measures). 
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